So, I'm learning C# right now, and I've got a couple of notes I thought 
I'd share...

1) The designers have decided that Garbage Collection is a Good 
Thing(tm), and that pointers are Dangerous.  So, while it's actually 
possible to use pointers, they spend a lot of time telling you not to.

I have to wonder, is the whole debate about GC merely due to the fact 
that current implementations aren't satisfactory?  If there were better 
implementations that were more predictable about object destruction and 
memory cleanup, and especially about when they clean up the fragmented 
memory space, would developers be more willing to live with it?

In fact, 10 years from now, is the debate over GC going to seem like the 
debate between C and C++: sure, C can be faster, but for most developers 
the benefits of C++ outweigh the negligible speed penalty.

Or is GC a flawed concept to begin with, and doomed to mediocre performance?

2) WHY is it considered a Good Thing that class methods must be written 
inline?  The language doesn't allow class prototypes, and claims this is 
a benefit because "header files aren't necessary."  I actually *like* 
header files, a well written one gives you a great overview of the class 
in question, and many times I refer to them rather than the 
documentation for class libraries.

Note: it may be that Interfaces solve this for me, I haven't gotten that 
far in the language yet.  In a few more days, I will have.

3) It's hard to believe how much some people are MS fanboys.  I picked 
up a number of C# books at the library (point of fact: I now have, in my 
possession, more books on C# from the local library, than my library had 
on *all* programming languages combined 15 years ago.  I know, because I 
read all of *those*, too).  Two of them have caught my eye, for being 
complete opposites:

The first has numerous errors in the code, and I mean extremely obvious 
things like:
   System.Console.WriteLine("Now assigning 10 to obj.value: ");
   obj.value = 20;
   System.Console.Writeline("Value of obj.value: {0}", obj.value);

Given that the above snippet is repeatedly (the program mentioned is 
repeated some four or five times), it's staggering to think that this 
error was never caught.  And it's only one example of the extremely 
sloppy editing.

Then, the author has the audacity to claim that MS's biggest mistakes 
with J++ were 1) Signing a contract with Sun, saying that they would 
accept Sun's standards on the Java language, and 2) Allowing the 
contract to be understandable.  These two items combined meant that when 
MS tried to "Embrace, Extend, Terminate" (or whatever that phrase is), 
Sun rightfully sued them and won.  Personally, I think their biggest 
mistake was to try to subvert another company's IP like that.

Now, this other book I'm reading has been edited well (I haven't found 
any errors in the code yet, or even in the grammar), and the author, 
despite writing a book on C# and obviously loving the language, still 
pokes fun at MS.  My favorite quote:
Q: How many OO programmers does it take to change a lightbulb?
A: None, MS changed the standard to darkness.

4) Lastly, sometimes it's the little things that count.  Personally, I 
love the fact that I don't have to right 'get' and 'set' functions for 
member variables, even when accessing the data is not straightforward.

Basically, C# allows you to give any member variable implicit get / set 
functions that are called when you access the variable normally.  In 
other words, you can access a member variable like this:

objA.val = objB.val;

And what will execute is:

objA.val_set( objB.val_get() );

Even though the variable 'val' can be a plain old int, or any other 
type.  I think this is really, really cool :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message